@kblok I have replaced various Dictionary<K,V> instances in Connection and the CDPSession classes with ConcurrentDictionary<K,V> instances because these dictionaries can be accessed concurrently from different threads. This was especially likely to happen when disposing Browser before all its send operations had completed. In some scenarios this led to race conditions between send, receive and dispose operations.

@ggeurts Can we revert that and discuss that in another PR?
I tested this PR locally last night and I got no leaks and I wanted to review what was here.
On the other hand, I was thinking over the concurrency deal. I don't want to add a lock on every dictionary call. I'm still which multi-thread scenarios we want to support.

@kblok I can revert, but it will result in a hanging test. The message sending and receiving portions of the code must deal with concurrency because nothing stops a client from initiating multiple sends before awaiting the results, or from disposing a browser when not all messages have been processed yet. I don't see a way here to achieve safe code without using locks. Having said that, I am willing to extract most of the latest changes into a separate pull request.

@kblok Ok, I have removed the ConcurrentDictionary use, but kept the gist of the other changes to prevent hanging tests. The likelihood of race conditions is less, but certainly still present.